Subject: MINIX - From the mouth of the horse
From: [email-masked] (Andy Tanenbaum)
Date: 8 Jan 87 23:11:03 GMT
Newsgroups: comp.sys.amiga,comp.sys.atari.st,comp.sys.ibm.pc,comp.sys.mac

I have just learned of quite a discussion going on in comp.sys.atari about
porting MINIX to the Atari.  For all I know a similar discussion is going on
in comp.sys.amiga and elsewhere.  I am cross posting this to several groups
in case there are people there who are interested in porting MINIX to their
machine.  If you missed the original note in mod.os.unix, I have just written
a UNIX clone that is available now with all the SOURCE CODE for $79.95 from
Prentice-Hall.  There is also a book telling how it works inside.
I suggest that subsequent discussion go on in comp.sys.ibm.pc to avoid 
scattering it all over the place.  At the very least, crosspost comments to 
comp.sys.ibm.pc under the subject MINIX. Later, we can set up comp.os.minix
if there is enough interest.

Read the comp.sys.atari group under the heading Forwarded for the last 2 weeks
to get the background for this note.

Although MINIX is copyright (not licensed), Prentice-Hall has agreed to permit
people to make a LIMITED number of copies for educational use, home study etc.
Posting the source code on the network (54K lines of C, kernel+utilities) is a
no no, but if each purchased copy doesn't generated more than say, 2 or 3 
copies it is ok. While this is not public domain it is a lot better than Lotus,
Microsoft, Borland, and every other software company in the world's policy.

About the pricing.  It is clearly not shareware, but by publishing the
source code on diskette, we are clearly not acting like AT&T either.
I had some discussion with people like Brian Kernighan (author of
the Software Tools package) and Doug Comer (author of Xinu, a little
embedded operating system for the LSI-11, although not really UNIX
like) and came to the following conclusion.  I would like to see MINIX become
widespread, so the distribution mechanism is crucial.  Having a major
publisher like Prentice-Hall advertise it, bring it to shows, send out
junk mail, etc. will get it a lot more attention than a note on the
net.  Getting a commercial publisher like Prentice-Hall interested means
charging something.  I think in the long run, this funny, copyrighted
but not real aggressive position we are taking will cause MINIX to become
widespread, new software to be made for it, etc.  The GNU people are
upset because deep in their hearts they, too, know that people would rather
pay a reasonable price for good stuff than get empty promises for free.
Does anyone know how much GNU charges for its "free" software for the tape,
postage, handling etc?    Berkeley generally charges something like $125
for its tapes, as I recall.  If GNU also charges $125 for its "free" software
it seems to me that their moral indignation at Prentice-Hall's outrageous
$79.95 price is somewhat weakened.  I mentioned MINIX in netnews last year
and I got quite a few reactions.  I have also contacted lots of people for
various reasons.  With two exceptions, everybody congratulated me and wished
me good luck.  Some people, especially Martin Atkins, Charles Forsyth, and
Richard Gregg gave me a lot of help, for which I am grateful.  Only two
people were really negative, almost bitter--both from the Free Software
Foundation (names withheld because I don't believe in character assassination
on a world-wide network).  I am tempted to comment further, but I won't.

As to the port to the Atari/Amiga/etc as far as I see, there are no technical
problems with the MMU.  The trouble is as follows.  When you fork, the
child has to go somewhere else in memory than where the parent was.
Unfortunately, the child's stack contains absolute addresses, such as
the return from the fork routine.  If the child runs somewhere other
than where the parent was, it will crash.

There are a couple of solutions, the simplest of which is this.  When the
child is created, record in the process table where the parent was.
When it is time to run the child, just swap the parent and the child,
and actually run the child where it belongs.  When the parent wants to
run, swap them again.  Although this sounds horrendous,  it is not at all
so bad.  Swapping two 10K programs in memory might take 30 millisec.
MINIX programs are small.  I am a strong believer in Small is Beautiful.
At the end of this note you will find the sizes of the MINIX utilities.
The only big ones are the compiler passes, cpp, cem, opt, cg, and asld.

Furthermore, 99.9% of the time, the child does an EXEC, at which point the
operating system can put the parent back where it belongs, and put the
new core image anywhere in memory.  In practice, all this trick will
cost is about two copies of the forked core image, and it doesn't require
modifying the compiler. My experience with fragmentation is that it is not bad.
MINIX doesn't swap because one of the design goals was to have it run on CHEAP
hardware (meaning a 256K PC with 1 floppy disk) and floppies are not ideal as
swapping devices.

The MINIX memory management scheme is very simple, because the PC's hardware
is primitive.  A core image consists of the text, the data, a gap, and then the
stack, growing downward.  The stack and the data segments grow into the
gap.  If they meet, BOOM!  In practice, very few programs have wildly
growing stacks or data segments.  I ran some statistics once, and for 90%
of the MINIX utilities, 2K stack is plenty.  On the PC, the text is limited to
64K, and the data + stack is also limited to 64K.  On a 68000, there would
be no need for such a limit.  It comes from the 8088 architecture.
All you have to do is change a couple of constants in the memory manager.

The book is already out.  You should be able to order it at any book store.
The title is Operating Systems: Design and Implementation.  The software 
will be out in three weeks.  It went into production about three weeks ago,
and it takes about six weeks.  Don't ask me why.  Probably the same reason
as why it takes Prentice-Hall 18 months to produce a book from the finished
manuscript (unless you give them camera ready copy, as I do).  If you want to
get the software (either on PC diskettes or 9 track tape), first order the book
and then send back the business reply card (software order form) in the book.

I would like to see a MINIX version for the Atari/Amiga/etc.  The 68000 is
clearly much better than the 8088, but the PC has a lot of software going for
it.  Maybe a tolerable UNIX clone might help the Atari/Amiga/etc in its fight
against the monster from 8088-land.  A colleague of mine at Philips has
already started to port MINIX to the Atari.  He is an absolutely top rate
programmer, but he is VERY busy, so he doesn't have much time.  I think he
has already rewritten the MINIX assembly code (low level interrupt
handlers, etc) for the 68000.  I will check with him one of these days; he
seems to be away right now.  What I would like to find is someone who:

(1) knows the Atari (Amiga, Macintosh, etc) hardware well 
(2) knows UNIX well on the outside and moderately on the inside
(3) has a substantial amount of free time
(4) has access to an IBM PC for testing things etc.  (not essential, but helps)

Perhaps such a person could do the port with a little assistance from me.
Unfortunately I don't have much time either, as Prentice-Hall is bugging me to
revise a book on networks I wrote a million years ago.

The main things to do, other than the 68000 assembly code, are the device
drivers, all of which are in C, but of course are totally different for
the PC and Atari etc.  The PC version doesn't use the BIOS at all, because the
stupid thing doesn't use interrupts.  When you start a background job up
and then start up the editor in the foreground, calling the BIOS to read
a character would put the whole computer in a tiny loop sitting and waiting
for the keyboard to produce a character.  MINIX supports the full UNIX
multiprogramming, so I had to write all the drivers from scratch (in C).  I 
suspect that the Atari BIOS isn't any better, although maybe we could use the
screen output BIOS.

And here we come back to the $79 again. If the person doing the port does a
good job, Prentice-Hall could sell the other version on diskettes, source code
and all, for the same $79 as the PC version.  I have enough clout with P-H
that I think I could arrange that.  Needless to say, the person doing the
port would be remunerated for his efforts, probably in the form of a royalty
on each disk set sold.  The royalty is typically only a couple of dollars,
but that small amount is why capitalism works and socialism doesn't.

If anyone is interested, let me know.  I don't think it will be that difficult,
but you have to plow through much of a very tightly written 719 page book and
understand a 12,000 line program before you can even start, so it will no doubt
be months of work.  Also, debugging operating system code on a bare machine
even a relatively nice one like the 68000, will be a fair amount of work.

One other point is the compiler.  The compiler is based on ACK, which is 
described in Communications of the ACM, Sept. 1983, pp. 654-660.  ACK is a big
system for writing compilers.  It is being distributed by UniPress in Edison
NJ and Transmediair in Utrecht, Holland.  It uses the old UNCOL idea of having
front ends that generate a common intermediate code and then back ends that
compile from that code to the target machine.  At present we have front ends
for C, Pascal, Modula 2, Basic, Occam, and even a subset of Ada. There are back
ends for virtually every micro around, from the 6502 to the 68020.  The ACK
software is owned by the university I teach at. UniPress pays them a royalty on
each copy they sell (academic price is $995 for a source tape containing 6
megabytes, although Modula 2 and Occam aren't on the tape yet).  Our department
doesn't have much money, and we use the royalties to allow grad students to go
to conferences and the like.  For these reasons the compiler kit is not part
of MINIX.    Furthermore even the 8088 C compiler source by itself fills 4
diskettes.  If the compiler source were in the MINIX distribution, that would
have meant raising the basic price to over $100, very much against my idea of
keeping the price low. I personally wrote MINIX in my spare time, which is why 
it doesn't have to follow the same rules as ACK.

Nevertheless, the source of the 8088 MINIX C compiler is available
as a separate package from UniPress.  I suspect that the easiest way to get
a 68000 C compiler is for someone at a university to have their university buy
the ACK tape and use that to develop the 68000 compiler.  When it is done, it
will be necessary to negotiate a deal with UniPress to allow it to be sold,
but I know Mark Krieger, the president of UniPress, and he is a reasonable guy,
so I am sure some deal can be worked out that won't raise the price too much.
He is on the net ([email-masked]) if you have questions about all this.

The reason that I think this route is the easiest, is that ACK already has a
backend for the 68000, so there isn't much work to be done, but you really
need a VAX or a SUN or something like that to bring up the full ACK development
system.  The compilers that are produced aren't so big, but the compiler-
compilers, and backend generators and the other meta-software doesn't really
fit easily on a PC.  In addition to the 6 megabytes of source code on the
tape, you have to count on at least 20 megabytes of object files and working
space to compile everything.  The 68000 compiler has been running for years
and it is pretty good.  We recently rewrote the backend table for the
68000, 68010, and 68020 and the code quality seems very good (about 15% better
than the C compiler Motorola sells).  I haven't even thought about using the
Pascal, Modula 2, Basic etc. front ends because I wanted the system to fit on,
and be able to recompile itself on a system without, a hard disk.  This
succeeded.  Technically there shouldn't be any big problem with the other
front ends.  Note that UniPress has TWO packages: 8088 MINIX C compiler, and
full ACK.  The former is 4 diskettes; the latter is 6 megabytes on a mag tape.

Andy Tanenbaum ([email-masked], or in emergencies, [email-masked])

Sizes of the MINIX commands

  Program  Text  Data   Bss  Total   (all sizes in decimal bytes)
    sync:   424    20    26    470
     clr:   714    28   156    898
  update:   836    42    58    936
   sleep:   848    58    58    964
      ln:  1070    86    74   1230
   chmod:   984    98   156   1238
basename:  1060    66   156   1282
     tee:  1228    82    94   1404
    kill:  1240    78   156   1474
  umount:   782   758    26   1566
   touch:  1348    76   156   1580
     sum:  1438    84   156   1678
   mknod:   930   738    26   1694
   mount:   890   782    26   1698
     pwd:  1546    84   172   1802
   mkdir:  1656   158    58   1872
   split:  1656   132   130   1918
     rev:   886    42  1052   1980
   rmdir:  1802   196   188   2186
     cat:  1212   722   540   2474
      mv:  2444   244    58   2746
    echo:   648    24  2076   2748
    stty:  2336   260   170   2766
      rm:  2468   276    30   2774
      df:  2030   948   156   3134
    time:  2584   666   266   3516
     lpr:  1314   126  2114   3554
    comm:  1822   104  2400   4326
      tr:  1470    82  2852   4404
   login:  3376  1436    28   4840
   chmem:  3178   278  2074   5530
    size:  3102   232  2208   5542
     tar:  4010   456  1774   6240
    head:  2762   168  3484   6414
      wc:  4460   208  2104   6772
      su:  3548  1498  2076   7122
      dd:  4966   532  2148   7646
   chown:  3522  2148  2074   7744
    date:  5338   412  2104   7854
      od:  5388   288  3654   9330
  passwd:  4976  1764  2620   9360
      pr:  5776   514  3110   9400
    sort:  6404   694  2490   9588
    grep:  6740   694  2208   9642
    uniq:  4956   850  5150  10956
      cc:  4404   826  5986  11216
   cc.at:  4404   834  5986  11224
    gres:  8496   768  2076  11340
    tail:  4550   184  7200  11934
      ar:  4900   488 11350  16738
    mkfs:  8708   906  7376  16990
    roff: 12742   820  4710  18272
      cp:  1914   876 16412  19202
    make: 15216  1976  3614  20806
    shar:   980    82 20506  21568
     cmp:  3372   224 18468  22064
 dosread:  7440  3688 11992  23120
   mined: 15680  2198  5308  23186
      sh: 21536  1668  1310  24514
      ls:  7164   584 17994  25742
     cpp: 16896  3764  8580  29240 (Pass 1 of the C compiler)
    asld: 14048  7882  7412  29342 (Pass 5 of the C compiler)
     opt: 16400  9368  9494  35262 (Pass 3 of the C compiler)
      cg: 24816 22968 10520  58304 (Pass 4 of the C compiler)
     cem: 59856 10656  3164  73676 (Pass 2 of the C compiler)